Subject: Setting Goals and Focusing our efforts

From: alan bartky <[email-masked]>
Date: Thu, 5 Aug 93 18:03:26 PDT

To: Fellow connect/disconnectors
From: Alan K. Bartky (chair)

Greetings again.  I apologize for not submitting mail on the status of
the group, as I have been fairly busy here at Sync Research with some other
projects.  Unfortunately it seems that everyone else is busy too as there
have been very few contributions as of late.

I have decided to postpone proposing a new agenda until we come to terms
about our work.  I must again state that we have a lot of work to do.
I believe that we should all first come to terms with our work and 
come to a group aggreement (consensus) on how to proceed.

If you are an active member,  I am asking you to have your answers on the
following subjects submitted by Tuesday 8/10 5:00 PM EDT to the mail exploder.
If you can do so earlier, please do so.  I will collect the mail and
and will issue a new agenda based on goals.  Once we have all agreed on
goals for the group, then work will proceed based on those goals.  Too much
of the discussion so far in the group has not been focused.  Based on your
input, we'll regroup and get to work again.

Required Questions for Active Members:

1) Do you believe that the current DLSw State Machine can be (or should
be) modified to support all of the following (for SNA PUs this includes
all combinations as far as the end stations being LLC or SDLC (i.e. full
interconnectivity))?

    Pu2.0
    PU2.1
    Other PU types
    Support for non equal SAPs (e.g DSAP=8, SSAP=4)
    NETBIOS

2) Does everyone agree that both NETBIOS and SNA should be supported
by DLSw?  (ref. Jim Cobban's mail message sent Aug. 3 on only including
SNA and excluding NETBIOS.)

3) Should the current mechanisms for sending the XID and TEST frames
be modified to not establish the DLSw circuit until SABME/UA or SNRM/UA
phase (e.g. like Cisco's Stun Mechanism)?

4) Should DLSw be modified to handle LLC type 2 connections for protocols
other than SNA or NETBIOS (i.e. generic LLC type 2 support)?

If you have any other questions or suggested goals please submit them
to the group ASAP.  Lets just have basic questions or goals only please.
We can haggle over protocol specifics once an agreement on goals 
is reached by the group.  All input is welcome!

I believe that we all would like to have a standard that we can all
agree on and work together on documenting.  But we must have discussions
that are productive.  No protocol is perfect, so lets not try and build
a perfect protocol.

Once we agree on goals then I have some sugestions on how to proceed with
the actual work.

We want a protocol that works for all cases we decide to do, and that is
documented well enough so that all companies can implement it.
All of us are very familiar with other "standards" documents that are not
clear and this only leads to interoperability problems.
The specification will have to include:

        A complete state machine (including all events in/out and timers)
        Full documentation of any implementation options.
        Full documentation on all events (frames, timeouts, conditions).
        Flow diagrams of all "normal" protocol flows.
        Flow diagrams of "typical" error path flows (e.g. line loss).
        Options in the protocol clearly documented as such.

Remember folks, this is your group.  If you want it to succeed then
it will take more work than just reading the mail.  If all we have are
readers, then there will be nothing to read and no work accomplished.
My job as chair will be to keep the group focused and working as a team.

From this point forward I will start setting some deadlines,
as appropriate, in the future to keep the work moving forward.

I believe the questions above will be easy to respond to, so please
get your answers in ASAP.

Thank you,
Alan K. Bartky ([email-masked])
Sync Research Inc.
Chair Connect/Disconnect Working Group

---

From: [email-masked]
Date: Mon, 09 Aug 93 15:49:51 PDT

>all combinations as far as the end stations being LLC or SDLC (i.e. full

    Yes.

>    PU2.1

    Yes.

>    Other PU types

    No.

>    Support for non equal SAPs (e.g DSAP=8, SSAP=4)

    Yes.

>    NETBIOS

    Yes ... but NetBIOS support could be an option set.  Cisco will
    defer to those with stronger feelings on this issue.

>SNA and excluding NETBIOS.)

    Yes ... but with the same qualifications as above.

>phase (e.g. like Cisco's Stun Mechanism)?

    I believe the standard needs to have ICANREACH/CANUREACH support
    for LLC2-to-LLC2 or SDLC(remote)-to-LLC2(host) like the RFC has.
    However, the Connect/Disconnect SIGlet needs to solve the problem
    for SDLC-to-SDLC tunneling as well as for LLC2(remote)-to-SDLC(host).
    When solving these DLC mappings, ICR/CUR might or might not be the
    solution.  This needs to be decided.

>other than SNA or NETBIOS (i.e. generic LLC type 2 support)?

    Eventually, yes ... but as a follow on activity after the first rev
    of the DLSw specification is complete.

>My job as chair will be to keep the group focused and working as a team.

    Remember too, Alan, that this is the summertime and most of us
    have vacations at one time or another (not to mention other
    projects :-).

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

---

From: Bernard Brady <[email-masked]>
Date: Wed, 25 Aug 93 10:16:26 EDT

Alan,

Sorry this is late but I've been on a mcuh needed vacation for the last
3.5 weeks and am attempting to catch up from where I left off at the end
of July.  

>all combinations as far as the end stations being LLC or SDLC (i.e. full
Yes	-	Pu2.0

Yes	-  	PU2.1

Other PU types - I belive that whatever we define should not hinder the
				support of other PU types.

Yes	- 	Support for non equal SAPs (e.g DSAP=8, SSAP=4)
>SNA and excluding NETBIOS.)

Yes, I think that both SNA and NETBIOS should be supported and specified
in the RFC.  I think it's an implementation issue whether to fully
support all features documented in the RFC.

>phase (e.g. like Cisco's Stun Mechanism)?

I prefer the current mechanism of setting up the DLSw cicuit and then
setting the link into either Asynchrous Balanced Mode or Normal Response
Mode. I beleive that if you do not establish the DLSw circuit until the
SABME/UA or SNRM/UA you will in most cases end up with a windows worth
of data  waiting for the circuit to be established.  This then means the
data has to be queued internal to DLSw until the ciruit is established. 
If the circuit is already  established then the data can be immediatley
queued to the circuit.

>other than SNA or NETBIOS (i.e. generic LLC type 2 support)?

I'm unclear on what this means. Does it mean a common LLC 2 interface
DLSw which  protocols can use as a common transport mechanism to get
data accross a backbone network?

>        Flow diagrams of all "normal" protocol flows.

This should also include currently implemented versus newly specified if
there is a difference.

Bernie